Nebula 2/Nebula Two.iso/SourceCode/MiscKit1.7.1/MiscKitArchive.mbox/mbox/000167_misckit-reques…aska.et.byu.edu_Wed Apr 6 15:23:21 1994.msg

Internet Message Format | 1994-10-30 | 4KB

Return-Path: <[e-mail]>
Received: from alaska.et.byu.edu by darth.byu.edu (NX5.67d/NX3.0M)
    id AA11713; Wed, 6 Apr 94 15:23:07 -0600
Received: from acs1.byu.edu by alaska.et.byu.edu; Wed, 6 Apr 1994 15:18:12 -0600
Received: from DIRECTORY-DAEMON by yvax.byu.edu (PMDF V4.3-7 #4169)
 id <[e-mail]>; Wed, 6 Apr 1994 15:18:13 MDT
Received: from alaska.et.byu.edu by yvax.byu.edu (PMDF V4.3-7 #4169)
 id <[e-mail]>; Wed, 6 Apr 1994 15:18:06 MDT
Received: by alaska.et.byu.edu; Wed, 6 Apr 1994 15:17:49 -0600
Date: Wed, 06 Apr 1994 15:17:49 -0600
From: [e-mail] (Don Yacktman)
Subject: Re: Comments on MiscAgent
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7BIT

> I suspect that if we are to find a truly usable suggestion, it would be
> best to start with an existing situation and work to abstract it.  Two
> classes that come to mind are MiscNibController and MiscInfoController.

I agree that this approach could lead to useful results.  As food for
thought, I didn't have time to make this change for the current release,
but the idea is to eventually have MiscInfo, MiscRegistration, and the
MiscOrderForm be subclasses of MiscNibController.  (This makes a lot
of sense if you look at things closely.)  The trick is that Chris'
MiscAgent idea then combines the features of the MiscInfoController
and the (soon to be) MiscNibController subclasses.  It partitions the
solution slightly differently.  I think the idea has merit, though,
since it seems it could be more extensible than the current solution.
The trick, as Ernie suggests, is to make sure that we are reducing
the complexity of the solution and not increasing it.  That's never
easy to do.  :-)

Anyway, I felt I ought to mention that I had intended to make the
above change, because it might change how you view the classes in
question.  Especially if you plan to make those classes be a starting
point for abstraction, you need to understand that the current
solution is not as good as if it descended from MiscNibController.
(Of course, anyone who has looked at those classes knows what I
mean.)  By the way, the genesis of those four classes is:  (1) I
started with Scott Hess' original InfoController from the archives
and added all these features to it for my games.  (2)  I abstracted
out the separate objects for info/registration/order form.  Until
NeXT added help in 3.x I had a help panel object too.  I threw it
out in favor of NeXT's solution.  The last step in the creation
was localization with string tables and Misc-izing; the latter was
(obviously) only done recently.  These are really old objects...
so be wary of using them as "examples".  They need a clean up in
their basic design, IMHO.  (It's a lot better than it was, though!)

Well, anyway, back to thinking this out.  By the way, I think
the hardest part will be making it transparent to set up knowing
what methods a class responds to before it is loaded.  You kind
of need a flat file--"object.info" or somesuch--inside the bundle
that the MiscAgent can look at before loading the bundle.  Trouble
is, you really need to make sure that that file is automatically
generated.  Making the developer have to worry about it makes the
set up a lot more obnoxious.  (BTW, my Preferences stuff that's under
construction needs to do something similar for the controls on the
preferences panel.  You need to know about what prefs exist...but
that's not possible without the .nib being loaded unless you set
up an easily parseable table.)

Later,
-don